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Abstract. This paper explores the offers and needs of service- oriented ar- 
chitectures (SOA) for modern cartography. Beside the overall concept of 
SOA its benefit for map production should be highlighted. This backend 
point of view on the IT architectural framework simultaneously delivers 
specific insight to the possible technical impact of SOA for an interactive 
map. It will show how minimum standards for the existence and perfor- 
mance influence the pragmatic dimension of a front-end map application 
and therefore wi 1 1 1 ead to the topi c of qual i ty of servi ces. 
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1 . Pragmatics of modern cartography 

Cartography may often be related with drawing images of topographic fea- 
tures. Modern cartography still uses the visual communication channel, but 
also adds a lot of features, which help to explore, understand and use a 
map. The modern map production lane uses a high digitized and partly au- 
tomated procedure and ends up in various products, spanning from paper 
maps, map clothes to any kind of digital devices. The Internet and devel- 
opment of the World Wide Web pushed the access to and usage of maps 
further [Peterson 2008]. Nowadays maps are accessible for everyone. Pro- 
vided that an infrastructure I ike the "mobile Web" and appropriate devices 
exist, ubiquitous cartography becomes enabled: map applications are avail- 
able everywhere and anytime. This kind of map distribution facilitates 
greater access to spatial information, increased interactivity design within 
and for maps, real-time information processing and intense integration of 
multimedia levels for geospatial information transmission. Furthermore 
mobile devices with GPS sensors support navigational tasks (mobile pedes- 
trian navigation systems) as well as data recording. This data collection by 
volunteers lead to an interesting initiative, which produces a worldwide 
crowdsourced dataset (OpenStreetMap) that is accessible for everyone. The 
main requirement for the wide success of OpenStreetMap is definitely the 
efficient backend architecture, which allows realtime mapping and produc- 



tive geospatial data handling in a way that not only experts can produce 
geospatial datasets [Coleman 2011]. 

All technological developments lead to a user understanding that a map can 
be ubiquitously used and even modified. This understanding means that a 
client can rely on map application quality, which covers data quality, per- 
formance, availability and even situation awareness. An evaluation of a map 
application by the user seems to be driven by a fulfilment of the pragmatic 
dimension in terms of geospatial communication. A review of search trends 
in Google shows that people are no longer searching for static maps but are 
increasingly looking for interactive services. This could bean indicator that 
efficient map applications in terms of information transmission are needed. 
The design, handling or functionality of a map application are core ele- 
ments for the user judgement, but as soon as the map application is prag- 
matically used, parameters concerning availability, response time or validi- 
ty become important. These parameters are created within the backend. 
Therefore modern map makers have to deal with IT architectures and their 
underlyi ng network technol ogi es. 



2. The backend and its influence 

The given examples show the importance of IT infrastructures and applica- 
tions for modern cartography. Most of these examples focus on the front- 
end, which is the user interface at the client side. It enables all the access to 
functionality and information transfer to the user. The impact on the users' 
imagery of the transmitted information is heavily triggered by all perceiva- 
ble effects of the user interface. Perceivable effects are the meeting point of 
the front-end and the backend. A lot of errors within the delivery processes 
of the backend could be perceivable in the front-end, which may lead to 
misunderstanding, misinterpretation and distortion of information. There- 
fore the backend plays an important role for the pragmatic dimension of a 
map/ map application and its acceptance by the user. 

The backend consists of several tiers that have to be considered. Most of us 
know that the Internet works with different network layers, its protocols 
and unique addressing. This network tier with its bandwidth and connectiv- 
ity is just one of a considerable series. Other important tiers in the backend 
concern the data-, service-, e-commerce- and client tier. 

I impact of the network tier: The network tier covers all aspects of intercon- 
nected components of the computer network. I n a very brief description the 
computer network is a telecommunications network - between data pro- 
cessing nodes - that is used for data communication purposes. The data 
processing nodes and endpoints are computers that are accomplished with 



various network hardware components. Two nodes are defined as "net- 
worked" if operations of one node are able to evoke operations on the other 
node (requests) and understands its responses [Tanenbaum 2006]. There 
exist several characteristics within the network tier that have an impact on 
thefront-end, I ike media that are used for signal transmission, communica- 
tion protocols that are used for network traffic organisation, the scale and 
topology of the network and its benefits and organisational scopes. 

Examples how the network tier impacts the front-end base upon the net- 
work performance, -security [Simmonds et al 2004] and - 
resilience. Network performance refers to the quality definition of a tele- 
communication product from the viewpoint of a customer. If we adapt this 
general statement to map applications, then the quality of a network's per- 
formance has to be designed according to the need of the map application. 
For the pragmatic use within modern cartography (e.g. mesh-ups) this re- 
quirement means that the network performance supports a fluent exchange 
with information within the network or at least allows performance enhanc- 
ing caching mechanisms. The network performance is one aspect that stim- 
ulates and enables on-demand interaction with the map. For the measure- 
ment of network performance various methods, like the ones for circuit- 
switched networks (1) or asynchronous transfer mode networks (2), can be 
used. This means that either (1) the number of rejected requests under 
heavy traffic loads or (2) data throughput, connect time or stability is meas- 
ured. 

The network security covers mechanisms and policies within the backend 
that prevents and monitors unauthorized access, use or modification. The 
access to use network components, applications or data is maintained by a 
network administrator. For the pragmatic dimension thefront-end needs to 
support authentication, network certificate detection or data decryption. 
These requirements may have some enormous impact on the pragmatic 
dimension if a user needs to login, accept certificates or needs specific plug- 
ins in order to decrypt information. In many cases interaction is needed and 
therefore disturbs map application usage or even information perception. 

Network resilience describes an acceptable level of "undisturbed" activity 
for normal network operations or services. This means that a service deliv- 
ers responses although threats and challenges, like simple misconfigura- 
tions or specific attacks, act on it. In order to enhance network resilience 
possible challenges and risks have to be identified. Appropriate metrics 
help to protect the network and its embedded services. Examples for net- 
work services are distributed processing, networked storage, communica- 
tion services like messaging or access to applications and information 
[Smith 2011]. 



Impact of the client tier: the client tier covers a client software, the de- 
vice/computer and even the user who uses the client software. It is a node 
component within the computer network that may also deliver information 
to the user. Therefore the client i nterface and the devi ce coul d be the front- 
end. But it also provides a backend with its client software, operating envi- 
ronment and/ or embedded servers. The client software sends requests to 
other nodes within the computer network and decodes its answers. A client 
software "web browser" connects to web servers and retrieves text and pic- 
torial information (webpages) that need to be i nterpreted for visualisation. 
The client is one main part of the client- server structure, where the clients 
connects to the Web or bind specific services. Servers generally wait for 
potential clients to initiate acceptable connections. Therefore the client 
needs to support network and interprocess communication standards in 
order to be understood and accepted by the networks as well as its servers 
[Shen2009]. 

Impact of the e-commerce tier: E-commerce (electronic commerce) is an 
industry branch where products or services are sold via electronic systems 
in computer networks. Modern e-commerce generally uses the I nternet for 
the diverse range of technologies such as the Web, e-mail, mobile devices, 
social media or smartphones. It draws on mobile commerce, electronic 
funds transfer, supply chain management, online transaction processing, 
electronic data interchange or automated data collection systems [Snider 
1992, Eisingerich 2008, Graham 2008]. The e-commerce tier facilitates the 
fi nanci ng and payment aspects of e-busi ness transactions. The e-commerce 
tier can be divided to the shared digital business infrastructure, the sophis- 
ticated model for operations and value-chains, a model to manage business 
teams, customers and partnerships as well as consistent policies, regula- 
tions and social systems [Zorayda 2003]. The e-commerce tier is another 
bridge between the front-end and the backend, which allows buying, license 
and usi ng i mportant information. The more the e-commerce tier is embed- 
ded in the real-time map production process, the less it disturbs infor- 
mation transmission. For instance a pop-up that asks for your banking ac- 
count and validation everytime map tiles are loaded will attract the main 
attention instead of the map application which should transfer the im- 
portant information. 

Impact of the service tier: within a service- oriented architecture the service 
layer can be considered as as bridge between the higher conceptual layers 
(Enterprise and process layers) and the lower ones (component and object 
layers), which is responsible for individual business operations [Bieberstein 
2005]. Services describe the functionality of a server- sided map application, 
which fetch data, information and operations from other nodes within the 
network in order to solve requests. E.g. cartographic mesh-ups intensively 



use various services to achieve predefined results. It may be obvious that 
increasing reliability and simplicity of services, in terms of reducing the 
need of interaction and requiring user knowledge, help to keep the users 
attendance on the important geospatial information transmission. 

I impact of the data tier: The data tier provides access to information. It co- 
vers its own application, conceptual- and physical tier, which allows access- 
i ng, structuri ng and persistent stori ng of i nformati on. The data tier i n terms 
of holistic backend description does not define the data transmission layer 
of the network, but the storage area/ management for a network- based map 
application, which could be distributed data sources throughout the Inter- 
net. The persistent existence, metadata as well as accessibility are main as- 
pects which are generally visible (or not!) in the front-end. If a dataset is 
not available anymore or it cannot be found because metadata are missing, 
then the map application in the front- end will show nothing. 

All the previously listed tiers show that the backend, the technical, logical 
and organisational structure behind a web-based map front-end, is a com- 
plex structure that heavily influences thefront-end. The reason to usea tier 
approach is the aim to reach independency between the tiers. This means 
that each tier is mainly independent from changes of other tiers. E.g. it is 
possible to exchange databases within the data tier and services will still 
work until their needed attributes exist; or thee- commerce tier can be mod- 
ified and the client will still be able to fetch a network connection if the 
same access variables exist. This means that a network-based map applica- 
tion is complex in terms of technical realisation and interdependency, but if 
the tier- and component- approach is considered, the maintenance of sys- 
tem components becomes feasible. The conceptual approach of service- 
oriented architectures follows a tier- and component- approach and there- 
fore offers some useful characteri sti cs for modern map appl i cati ons. 



3. SOA offers 

A service- oriented architecture (SOA) is a conceptual model for a network 
of distributed systems, applications and data, which uses standardized in- 
terfaces between the tiers [Erl 2004]. 

I n the techn i cal perspecti ve the SOA pri nci pi es make use of a stri ct di sj unc- 
tion of the types "user- interface", "application", "interfaces", "system tiers" 
and "data" [Bell 2008]. For the conceptual design these components are put 
to different layers according to their types, which enables independency. I n 
fact the technical perspective of SOA uses well-defined standards for all 
interfaces between the tiers. Only the definition of a wide spectrum of 
standards al I ows the I oose coupl i ng of the ti ers. 



The loose coupling means that the interfaces are standardized, well de- 
scribed and independent from proprietary (black- box) structures. Anyway a 
proprietary application can be embedded as soon as it supports these inter- 
face standards. The same applies for the data components. For this reason 
the value adding composition of SOA components [Goncalves 2011] is sup- 
ported, which creates one of the most i mportant economic aspects of SOA. 

In general the basic SOA concept is made up of eight main design principles 
originating from IT Web service development and business process man- 
agement. In the foil owing some of these principles will be described and it 
wi 1 1 be tempted to show thei r i importance for the f rontend/ map appl i cati on 
of a servi ce ori ented map. 

The service loose coupling describes that a component can be used with 
little or no knowledge of its defi nitions by other components. The usage of a 
flexible file format such as XML for the description of a service or data and 
its schema faci I i tates a I oose coupl i ng of i nterfaces. 1 1 enabl es subscri bers to 
extract clear definitions of how to use a service and its data. A subscriber 
could publish the collection of statements, which are used and created with 
a service. This would allow a responsible data- or service provider to test 
whether their subscribers need adaptations of their interfaces if modifica- 
tions are made on data or service. Any reducing of information that has to 
be passed i nto a servi ce as key data coul d enhance I oose coupl i ng. 

I n terms of the front-end (map application) loose coupling also enables in- 
dependency from the service content. E.g. a service that provides the con- 
tent of a webshop will change this information according to sortiment 
changes. If loose coupling is enabled then these changes do not have any 
effect on the interface because it stays the same and the sortiment will be 
modified automatically based on the new delivery of the service. If a front- 
end is based on the content of the webshop, then every change of the sorti- 
ment causes an adaptation of thefront-end. 

The pri nci pi e desi gn i dea of SOA counts on reusabl e servi ces. A servi ce that 
is created once can be used often. Those services embed a "solution logic" 
that is independent of specific business processes or technology. In many 
cases these Web-enabled services are designed to be platform-, software 
framework- and business model independent. 

Apart from the technical realization of service reusability, the embedding of 
thisdesign pri nci pie performs a top-down analysis process, which resultsin 
a compl ete set of usabl e servi ces. I n fact this gatheri ng of candi date servi ces 
require increased resources. In the end a significant amount of resources 
can be saved because of eliminating the full development procedure. One 
important assumption to fully apply service reusability is the given cultural 



basis: do service developers reuse others services? Do map makers allow 
existing services to be incorporated as possible solution although further 
design adaptations are needed? If the cultural basis does exist, then the 
given emphasis on service reuse leads to the issues of reliability. A reused 
service as part of new services provides its functionality to multiple service 
customers. If its quality of service is not reliablethen all incorporating ser- 
vices will lack of reliability. 

A geospatial example could be a web map service that is used as layer in 
other web map services. The resulting service outcome relies on the availa- 
bility and delivery of the embedded web map service. Because temporary 
malfunctions of these services may occur, caching technologies try to over- 
come this disaffection. This method tries to establish service autonomy for 
short time periods, in which the cache of a web map service delivers the 
content. Service reusability highlights the main requirements for a prag- 
matically useful SOA, which can be subsumed to the notion "quality of ser- 
vice". 

Service discoverability is a key component of the "search-find- bind" proce- 
dure, which defines how resources can be found and thus describes the 
general sequence of service invocation. Service metadata becomes pub- 
lished to a central register, which allows searching and finding for services. 
Therefore service discoverability increases service reuse and decreases 
functional redundancy of services. The development of services with the 
same functionality becomes obvious. Indirectly, discoverability makes ser- 
vices more interoperable, because specific functionalities can be found and 
used. 

An effective realisation of this design principle requires standardized 
metadata in consistent and meaningful manner. Therefore service develop- 
ers have to be enforced to use and apply existing metadata standards when- 
ever possi bl e. Core defi niti ons of metadata are the mandatory part and may 
be extended with individual optional supplementations. 

Following the principle of service abstraction, service discoverability calls 
for a mi ni mum set of metadata attri butes i n order to make servi ce discover- 
able. This inversely dependency has to be considered within the architec- 
tural concept of service infrastructure creation. This direct relation leads to 
a careful separation of the general service metadata and its external func- 
tionality description from the internal, not documented service procedures, 
which should not be embedded within the service metadata. 

The existence of metadata for services and data allow for an automatic 
binding process of these resources into a front-end. E.g. information com- 
i ng from observati on sensors coul d di recti y be embedded i nto a map. 



The principle of service composability encourages the reuse of services in 
various and multiple solutions as well as defines that services themselves 
may be made up of composed services. Therefore any recomposition does 
not depend on the size and complexity of a service composition. Composa- 
bility is one main aspect of SOA, which promotes new service solutions by 
reusi ng existi ng ones and therefore support a val ue addi ng chai n by techno- 
logical independency. 

Several considerations have to be kept in mind: with a growing number of 
service compositions, some services will get highly reused because they ful- 
fil basic needs. Hence these compositions will become dependent on the 
selected services they share with all the other compositions. It is foreseeable 
that such service compositions will lead to critical functionality. I n order to 
avoid thesecritical situations alternate standby services will be needed, 
which means that a calculated number of redundant services need to be 
allowed and the composition architecture has to be precisely analysed and 
designed. A solution of "how and when to use standby services" could be 
embedded i n a servi ce contract. 

The quality of provided components covers standardization and appropri- 
ate communication of data/ information quality on one hand and service 
quality on the other. These requirements for quality describe central needs 
for SOA- based map applications. 



4. Needs for SOA-based maps 

The central needs for SOA-based map applications from the viewpoint of 
the front-end (the map as user interface) are quality agreements for all sys- 
tem components/ nodes. The conceptual idea of service- oriented architec- 
ture supports ongoing changes and thus a "living system". This means that 
components/ information sources can be added, modified or removed. Like 
in the World Wide Web the whole system is changing. We know examples 
of webpages showing broken links to images, which have been removed 
from their source, or blogs that show up new information every day. This 
fact can also be adapted to the service- oriented map application. In addi- 
tion to missing information layers, the quality of embedded services will 
decide on success of the application: How fast is the response? Are there 
peak times, when the service produces errors? Are there offline times? Is 
the qual ity of the content homogeneous enough for the mesh-up? 

I n the role of the mapmaker, who uses SOA and depends on data and ser- 
vice quality, a certain degree of confidence into the nodes is needed. There 
are two dimensions that have to be considered before a source can be added 
to a map product: data quality and service qual ity. 



Data quality is directly related to the recording, generation and processing 
of geospatial data. The specific aim and its aggregation from other sources 
may have impact on its quality. Descriptions of data processing as well as 
the initial aim of the data product are important hints, beside a lot of others 
like dataset consistency, -validity, etc., if a dataset could be used as source 
information. All these describing elements will give no indication if the 
information is homogeneous with other data sources. In general it needs 
further processing in order to be homogeneous within the map application 
[Hopfstock 2012, Schmidt etal 2012]. 

Service quality helps to reach the main principles of SOA. It takes the usage 
of appropriate standards, schema consistency and precise documentation 
as a given, in order to reach the aim of automatization (as computer-to- 
computer communication). But there is one aspect that is not controlled 
withinthe establishing process of services (I ike standards, documentation) - 
the quality of a service underlies IT infrastructure, its architecture, security 
and operation management. I n the end this aspect informs about reliance of 
a service. This value can be directly used in the resulting reliance descrip- 
tion of a SOA-based map application which has to use the worst embedded 
source i n terms of rel i ance. 

The quality of service convention is needed for SOA-based map applications 
in order to support the pragmatic dimension. Herein three positions have to 
be considered: availability, performance and capacity. 

Availability assures that a service is available for the time of its being. This 
means that it would have a described "uptime". I n terms of organizational 
structures the uptime of a service could be described by the time of supervi- 
sion, e.g. Monday to Friday, 9 a.m. to 5 p.m.. In fact it does not make sense 
for a SOA to embed services that will be switched off for the weekend, espe- 
cially within international usage. Therefore the uptime of a service is meant 
to be 7days/week and 24 hours. A planned and unplanned downtime ratio 
could be defined and communicated within metadata. This allows for de- 
tailed planning and definition of reliance in terms of availability. 

Performance descri bes how long a service needs to send a response. Obvi- 
ously a reference frame and amount of data has to be specified so that this 
time span makes sense. Still there will be enough variance for the interpre- 
tation, e.g. the measures timespan counts from receiving the first byte up to 
sending the first byte. This example interpretation would remove network 
traffic from the value. Another possible interpretation could be to measure 
the f i rst byte sent by an cl i ent up to recei vi ng the I ast byte of a response at 
the cl i ent (i nformati on transfer compl ete) . 



Capacity indicates how many parallel requests can be completed without 
generati ng errors or i nf I uenci ng performance. Dependi ng on the amount of 
parallel requests, a service may need more time to response a request 
(queuing) or it will abort a request. Both situations are the result of reach- 
ing a maxi mu m capaci ty of the servi ce. 

In the role of a map user data- and service quality are observable in the 
front-end. For many users service quality is the more serious matter than 
data quality. The reason issimple: a service should beavailableon demand. 
It should deliver valid results within a meaningful timeframe. Therefore 
servi ce qual ity di rectly supports the pragmati c di mensi on of a map appl i ca- 
tion and is the most important aspect for a successful information trans- 
mission. 



5. Resume and future aspects for a SOA based car- 
tography 

This contribution focuses on the backend of modern cartography and how it 
influences information transmission through the front-end. The backend is 
either used for digital map production or SOA-based map applications. In 
both cases the impact on the front-end is enormous and leads to disaffec- 
tion, misunderstanding or frustration. Some influence on information 
transmission is indispensable. Modern cartography builds on technological 
backend structures. There is a direct dependency of modern (SOA-based) 
map applications to these structures - without the backend the digital map 
will not work. 

We could show that the pragmatic dimension for geospatial information 
transmission with modern technologies depends for a large extend on 
backend architectures. Even the basic technical structures, I ike the network, 
do have thei r i impact on the user i nterface. I n order to reach i ndependency - 
in a way that maintenance and component updates become feasible - a tier 
approach can be established. This tier approach is build on standardized 
interfaces and services - the basic concept of SOA. The SOA concept follows 
simple rules of the World Wide Web, which are adapted to other domains 
like maps in the Internet. This conceptual approach generally brings in in- 
dependency between the different tiers by following specific design princi- 
ples, but it does not remove the impact of the backend characteristics on the 
front-end/ user interface. We could highlight that the main sources that may 
influence information transmission are data quality and service quality. 
Whereas data qual ity can be described prior, service quality callsfor experi- 
ence in IT architectures and predictions of service usage. Service quality is 



the result of specific IT architecture construction and load (processing, 
network, DB) removal methodologies. 

I n the end the map application user does not care about the backend struc- 
tures. Within a SOA-based map application the user will never be able to 
explore IT architectures and he/she may not have the knowledge to do so. 
But the impact of backend architectures will be observable in thefront-end. 
The map user is affected by slow answers of the system, availability of in- 
formation layers or random failures in situations when the information is 
needed. 

An evaluation of future trends shows that SOA-based cartography will in- 
crease in the coming years. Spatial data infrastructures, which are the 
sources for geospatial information, are established throughout the world 
and provide easy and standardized access to these sources. Additionally 
recordings of real-time sensors, which are published with standardized in- 
terfaces, increase the number of information sources. Mapmakers learn 
how to deal with real-time information and how to combine different 
sources in a homogeneous way. Complementary we have to learn how to 
deal with a large amount of geospatial data services and their changing be- 
haviour. How can we evaluate the right services for our map application? 
What are the quality enhancing methodologies for map production in SOA? 
How to achieve sustainability? How to approach the pragmatic dimension 
of geospatial communication? A lot of questions go along with SOA-based 
map appl i cati ons and the f ulf i I ment of the pragmati c di mensi on i n terms of 
communication in future. 
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